The Short Messaging Service (SMS) has become a key feature of cellular communication systems, particularly those based on the standards developed by the Third Generation Partnership Project (3GPP). SMS messages are addressed to a particular mobile subscriber using the Mobile Subscriber ISDN (MSISDN) identity. 3GPP TR 21.905 defines an MSISDN as being an ISDN number. This is equivalent to a number as defined under International Telecommunications Union (ITU) E.164 Standard.
Referring to FIG. 1, there is shown a diagrammatic representation of a simplified message flow for the existing routing of Mobile Originating (MO) SMS data. Messages flow between the following entities: a first User Equipment (UE) 10; the visited Mobile Switching Centre (MSC) 20 for the first UE 10; a Short Message Service Centre (SMSC) 30 in the Home Public Land Mobile Network (HPLMN) of the first UE 10; a Home Location Register (HLR) 40 of a second UE (not shown), which is the recipient of the SMS data; and a visited MSC (VMSC) 50 for the second UE.
An initial step 100 takes place before the first UE 10 has decided to send SMS data. The first UE 10 registers in the visited MSC 20 (which may alternatively be a Serving GPRS Support Node, SGSN). The MSISDN of the first UE 10 is stored in a Visitor Location Register (VLR, not shown). This is downloaded by the HLR (not shown) of the first UE 10. The database storing the MSISDN of the first UE 10 may equivalently be in an SGSN instead.
The first UE 10 sends SMS data to the second UE. Both the first and second UEs may each be alternatively identified as a Short Message Entity (SME). The address of the SMSC 30 for the first UE 10 is sent as an Information Element (IE) in the RP-Data message transmitted by the first UE 10 and shown in step 110. The SMS message and the address of the second UE are both inside the Transport Protocol Data Unit (TPDU) IE in the RP-data message.
The Visited MSC (VMSC) 20 (or SGSN) opens a Charging Data Record (CDR) for the SMS in step 120. The CDR includes the MSISDN and International Mobile Subscriber Identity (IMSI) of the first UE 10, the address of the SMSC 30 and the address for the second UE (extracted from within the TPDU). This is described in more detail in 3GPP TS 32.250 and TS 32.251 and their definition of OM.
In step 130, the VMSC 20 (or SGSN) sends the SMS data to the SMSC 30 of the first UE 10. The address used in the Signalling Connection Control Part (SCCP) is the address of the SMSC 30 in E.164 format. The SCCP payload includes the TPDU (the SMS message and the address for the second UE), the IMSI and MSISDN of the first UE 10 and (duplicated) the address for the SMSC 30. The IMSI of the first UE 10 is included for mobile number portability reasons.
The SMSC 30 of the first UE 10 interrogates the HLR 40 of the second UE in step 140. This assumes that the terminating SME (that is, the second UE) is a mobile subscriber. The address used at the SCCP level is the MSISDN of the second UE in E.164 format. However, the MSISDN for the second UE and the address of the SMSC 30 are also contained inside the payload.
In step 150, the HLR 40 returns the IMSI of the second UE and the address for the VMSC 50 of the second UE. The SMSC 30 then creates a CDR (and/or performs online billing) in step 160.
The SMSC 30 then forwards the SMS message to the VMSC 50 of the second UE in step 170. The VMSC 50 uses the IMSI provided in step 170 to locate the VLR record of the second UE and then tries to deliver the SMS data to the second UE. Mobile Application Part (MAP) is used for transfer of the SMS data in steps 130 and 170. In step 180, a CDR record is opened.
Mobile number portability is another relevant factor to be considered in the routing of SMS traffic. This is further complicated by the way that the user of the first UE 10 might input the address for the recipient second UE. Two different numbering schemes may be used: a) a full International MSISDN (for example, “+44 7748 abcdef”); or b) a “National” number (for example, when a UK mobile terminal contacts another UK mobile terminal, a number such as “07748 abcdef” may be used, even if roaming). In case b), the SMSC 30 converts the number beginning “07748” into “+447748”. Commercial SMSCs may also have significant number translation functionality, for example to handle short codes for the second UE.
Referring next to FIG. 2, there is shown a schematic representation of a simplified message flow for existing SMS routing when mobile number portability is used. Where the same features (whether entities or message flow steps) are shown in FIG. 2 as shown in FIG. 1, identical reference numerals have been used. Some of the steps shown in FIG. 1 have been omitted from FIG. 2, simply for clarity purposes (such as CDR opening), but it will be understood that these also take place in the implementation shown in FIG. 2.
An additional network entity is provided in FIG. 2 when compared with FIG. 1. This is a Mobile Number Portability (MNP) entity 35. In some PLMN architectures (for example, in the UK) the MNP entity 35 is placed in the donor network (that is, the PLMN that originally issued the MSISDN to the mobile subscriber). However, other implementations place the MNP entity 35 in the Signalling System 7 (SS7) network of the home country.
As with FIG. 1, in this implementation, the first UE 10 sends SMS data in step 110 to the visited MSC 20. The MSC 20 forwards this data to the SMSC 30 in step 130. However, the SMSC 30 then issues a Send Routing Information (SRI) for Short Message (SM) request in step 240 to the MNP entity 35. The address at the SCCP layer is the MSISDN of the second UE in E.164 format.
The MNP entity 35 then consults a lookup table to determine if a second UE has been ‘ported’ out of the donor network. In other words, the second UE might not actually be a subscriber to the PLMN in which the MNP entity 35 is located, but it may have been previously. If this is the case, then the MNP entity 35 inserts an SCCP address that points to the home PLMN of the second UE (also known as a recipient network). This may be the exact address of the HLR 40 of the IMSI of the second UE. The contents of the SRI for SM need not be changed. This takes place in step 245.
The HLR 40 of the second UE (that is, in the recipient network) uses the MSISDN in the SCCP payload to retrieve the address for the visited MSC 50 of the second UE. The HLR 40 of the second UE then sends the SRI for SM acknowledgement directly back to the SMSC 30 of the first UE 10. This system functions effectively for provision of SMS data in existing configurations.
Machine Type Communication (MTC) devices are increasingly being employed on cellular communications networks. Many of these devices are intended to operate Packet Switched (PS) services only. 3GPP TS 22.368 (v11.2.0) contains requirements for so-called “Packet Switched (PS) only” operation. A brief extract is reproduced here for convenience.
“7.2.4 Packet Switched (PS) only
The MTC Feature Packet Switched Only is intended for use with MTC Devices that only require packet switched services.
For the Packet Switched Only MTC Feature:                A network operator shall be able to provide PS only subscriptions with or without assigning an MSISDN.        Remote MTC Device triggering shall be supported with or without assigning an MSISDN.        Remote MTC Device configuration shall be supported without the use of an MSISDN.        
NOTE: Current remote MTC Device configuration solutions (i.e. Device Management and Over-the-Air configuration) are based on SMS, which assumes the use of MSISDNs.”
This means that MTC devices are intended to make use of SMS and it is therefore desirable that they be identified with use of an MSISDN. Although most discussion has focused on SMS from server to MTC devices (such as triggering), it is likely that some MTC devices (for example, games consoles) may benefit from the ability to be contacted from human devices, including “legacy” human devices. Similarly, the user of the MTC device may wish to communicate with a “more human” device.
Issuing an MSISDN using E.164 format to MTC devices is not straightforward though. Limitations within the E.164 format mean that the quantity of unique MSISDN identities that can be issued is restricted. The potentially large number of MTC devices may exhaust the available MSISDN identities using E.164 format. E.164 number shortages are discussed in 3GPP TR 22.988 (v1.1.0) entitled “Study on Alternatives to E.164 for Machine-Type Communications (Release 10)”.
One option to address this difficulty is for MTC devices to use SMS with a non-E.164 MSISDN. As indicated above, the current message flow for SMS data relies on MSISDN information in E.164 format. Adapting the SMS message flow to allow the use of non-E.164 MSISDN with minimal impact to the network architecture and message flow is a significant challenge.